Method and apparatus for submitting user content in dcd service

ABSTRACT

Apparatus and method for uploading/submitting user-created content to share with other users in a Dynamic Content Delivery (DCD) technology capable of supporting various types of delivery systems to deliver user-customized content. The invention provides an environment where a user creates content according to a predetermined rule and submits the content with associated content information, so that a DCD service provider can easily handle the content after receipt.

PRIORITY

This application claims priority under 35 U.S.C. §119(a) to a KoreanPatent Application filed in the Korean Intellectual Property Office onAug. 8, 2008 and assigned Serial No. 10-2008-0078135, the entiredisclosure of which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and apparatus for deliveringcontent in a Dynamic Content Delivery (DCD) service. More particularly,the present invention relates to a method and apparatus for submittinguser-created content to share with other users.

2. Description of the Related Art

Due to the development of communication technologies, mobilecommunication, which focused on voice calls at its initial stage, is nowintroducing to the market messaging services such as Short MessageService (SMS) and Multimedia Messaging Service (MMS), and varioussupplementary services such as Internet access service and video callservice, and is also considering the introduction of personalizedcontent delivery services taking into account the fact that a majorityof mobile communication devices are carried by individuals.

Considering such market characteristics, Open Mobile Alliance (OMA),which has established many application layer standards for portableterminals, is conducting research on a Dynamic Content Delivery (DCD)technology in the OMA Content Delivery (CA) Working Group, it's the OMAaffiliated organization. DCD is a technology capable of providingservices that deliver user-desired contents on a personalized basis inline with the situations that practical application of Internet serviceson mobile terminals is not made because of the market demands statedabove, the inconvenient searches, the limited input means, and the lowservice speeds, and with the growing user demands for personalizedservices.

Problems of the prior art and solutions for addressing the same will bedescribed clearly below based on an OMA CD technology, which is one ofthe content provision standards. However, this is a mere example used togive better understanding of the invention, and the present invention isnot limited to the OMA CD technology and can be applied to various othercontent provision technologies.

FIG. 1 illustrates the architecture and interface configuration of a DCDservice system to which the present invention is applicable.

Referring to FIG. 1, the DCD system includes a DCD client 120 and a DCDserver 110. The DCD client 120 is located in a mobile terminal and usedby the mobile terminal to access the DCD server 110. The DCD client 120includes modules that perform their associated three logical functions:a Subscription and Administration function, a Content Delivery andStorage Management function, and a Client Application Interactionfunction. The Subscription and Administration function module 121 isresponsible for exchanging service administration information with theDCD server 110, and the Content Delivery and Storage Management functionmodule 123 is responsible for managing content received from the DCDserver 110. The Client Application Interaction function module 125supports functions for accessing the DCD service from a DCD EnabledClient Application 20 using its DCD client 120.

The DCD server 110 offers a network function based on DCDservice-related applications. The DCD server 110 includes modules thatperform their associated two logical functions: a Subscription andAdministration function and a Distribution and Adaptation function. TheSubscription and Administration function module 111 is responsible forexchanging service administration information with the DCD client 120,and the Distribution and Adaptation function module 113 provides DCDcontent and a DCD content notification to the DCD client 120. Table 1below defines interfaces used between the components (logical entities)in FIG. 1.

TABLE 1 Interfaces Definition DCD-1 Bi-directional point-to-pointinterface between the DCD Server and the DCD Client. This interface isused by the DCD Client to send content requests to the DCD Server, andto receive responses. DCD-2 Uni-directional interface between the DCDServer and the DCD Client. This interface is used by the DCD Server topush notifications and/or content to the DCD Client. The DCD-2 interfacecould manifest itself as point-to-point push interface orpoint-to-multipoint broadcast interface. DCD-3 Bi-directionalpoint-to-point interface between the DCD Server and the DCD Client. Thisinterface is used by the DCD Server and the DCD Client to exchangeservice administration and configuration information. DCD-CPRUni-directional interface between the DCD Content Provider and the DCDServer. This interface is used by the Content Provider to register newcontent channels with the DCD Server. DCD- Bi-directional interfacebetween the DCD Content Provider and the DCD Server. This interface isCPDE used by the Content Provider to publish content at the DCD Serverand by the DCD Server to retrieve content from the Content Provider. Theinterface could also be used for exchange of administration information,if applicable. While the interface is bi-directional, only the DCDServer provided interface functions are a subject for standardization.DCD-CAR Uni-directional interface between the DCD-Enabled ClientApplication and the DCD Client. This interface is used by theDCD-Enabled Client Application to register with the DCD Client when theapplication is installed on a handset. DCD- Bi-directional interfacebetween the DCD-Enabled Client Application and the DCD Client. This CADEinterface is used by the DCD Client to send notifications and/or contentto the DCD-Enabled Client Application and by the DCD-Enabled ClientApplication to retrieve content from the DCD Client. The interface couldalso be used for exchange of administration information, if applicable.While the interface is bi-directional, only the DCD Client providedinterface functions are a subject for standardization.

In the DCD system, content metadata (Metadata, Content Format) isdefined to deliver content. The term “content metadata” refers todynamic settings and rules, or content information, for controlling DCDcontent delivery. Table 2 below gives definitions of elements andattributes in the content metadata.

TABLE 2 Provided to DECA(DCD Enabled Originated Client Name TypeCardinality Description Data Type Used by from Application) content- E 1Contains the Structure DS(DCD CP(Content YES metadata following Server),Provider) attributes: DC(DCD content-updated Client) content-idchannel-id mime-type content-length content-types content-namereplaces-content- id content-price content-delivery- notificationdelivery-priority content-encoding content-address content-storage-location content-block-id parental-rating deliver-to deliver-at content-expiration delivery-spread deliver-when- roaming network-selectionaux-content-link Contains the following sub- elements deliver-per-location deliver-per- presence deliver-per-xdms content- A 0 . . . 1Time when the String DC CP, DS YES updated content item was lastupdated. SHALL conform to the “date-time” definition in [RFC3339]. Inaddition, an uppercase “T” character SHALL be used to separate date andtime, and an uppercase “Z” character SHALL be present in the absence ofa numeric time zone offset. content-id A 1 Identifier set by String DS,DC CP YES the Content Provider, and unique within the DCD ServiceProvider's domain. The main purpose of the content ID is to enableapplication level confirmation and resumption of content delivery.Implementation in XML schema will use the “AnyURI” data type. channel-idA 0 . . . 1 A list of Channel List of DS, DC CP YES IDs as assignedStrings by the DCD Server. The Content Provider includes this attributeto associate content items with DCD channels mime-type A 1 The MIME typeString DS, DC CP YES of the content item. content- A 1 The size in bytesString DS, DC CP, DS YES length of the content item. content- A 0 . . .1 A list of strings List of CP YES types that describe the Stringschannel content to enable association or filtering e.g. by “type”,“category”“tag”, or “relation” content- A 0 . . . 1 Name of contentString CP YES name in a human readable format. replaces- A 0 . . . 1Content ID of an String DS, DC CP YES content-id outdated content itemthat, if present in the storage of the DCD Server or DCD Client, shouldbe replaced with this content item. Implementation in XML schema willuse the “AnyURI” data type. content- A 0 . . . 1 Indicates the String DCCP, DS YES price price (amount and currency) of this content item. Thepurpose is to let the user know the price of the content and decide ifhe wants to retrieve it content- A 0 . . . 1 Indicates the need BooleanDS, DC CP, DS NO delivery- for, or status of, notification deliveryacknowledgement for this content item. This attribute should be set to“true” if user is charged for delivery of this content item (subject toDCD Service Provider Policy) Values: 0 - False (*) 1 - True delivery- A0 . . . 1 The delivery Enumerated DS, DC CP, DS NO priority priorityassociated with this content item. Values: 1 - Low 2 - Medium (*) 3 -High 4 - Emergency content- A 0 . . . 1 Encoding that has String DC DSNO encoding been applied to the content item, e.g. GZIP or deflatecompression. content- A 0 . . . 1 An address String DC DS YES address(URL) where the content item can be directly retrieved by the DCD Clientvia the DCD-1 interface. content- A 0 . . . 1 Location of the String DCDC YES storage- content item in location the DCD Client managed storagecontent- A 1 Identifies which String DS CP YES block-id multiple contentitems can be associated as a block. May be used by the DCD Server forcontent aggregation/ bundling. parental- A 0 . . . 1 Content rating perString DS, DC CP YES rating FCC “TV Parental Guidelines” or similarlocal regulatory requirements. May be used by the DCD Server for contentselection/ filtering, and by DCD Client for the same in the broadcastcase. deliver-to A 0 . . . 1 A particular set of String DS CP NO usersto receive the content. deliver-at A 0 . . . 1 Time at which the StringDS CP NO DCD Server should deliver a content item. content- A 0 . . . 1The expected String DS, DC CP YES expiration lifetime of the contentitem in device storage, and the time until which the content item can bedirectly retrieved (if a content address attribute was provided).delivery- A 0 . . . 1 The period over String DS CP NO spread which theDCD Server can randomize delivery, for the purpose of load spreading.deliver- A 0 . . . 1 Indicates whether Boolean DS CP NO when- thecontent item roaming should be automatically delivered or retrieved viapoint-to-point interfaces if the user is roaming Values: 0 - False (*)1 - True network- A 0 . . . 1 Descending String CP, DS, DS NO selectionpriority-ordered, comma-separated list of network/bearer types for usein content delivery, selected per arbitrary deployment- specificcriteria for network selection (e.g. GPRS vs. UMTS vs. Wi-Fi) based ondelivery cost, bandwidth, quality of service, etc. DCD Client and DCDServer apply these criteria for content delivery over DCD-1 and DCD-2interfaces. One or more of “UMTS”, “WiMAX”, “LTE”, “802.11”, “CBS”,“BCAST”. aux- A 0 . . . 1 Provides the String DS, DC CP, DS NO content-Content ID or link link to additional content that is related to thecontent being delivered. The intent is to support pre- fetching contentreferred to by the main content item or likely to be requested later.deliver- E1 0 . . . 1 A rule for String DS CP NO per- matching alocation location at which delivery should be allowed. The rule shouldbe specified by the DCD Content Provider, the DCD Server, or the DCDEnabled Client Application based on the format published by the ServiceProvider deliver- E1 0 . . . 1 A rule for String DS CP NO per- allowingdelivery presence based upon matching a Presence attribute deliver- E1 0. . . 1 A rule for String DS CP NO per-xdms allowing delivery based uponmatching a XDMS attribute.

In the prior art, the content metadata for content delivery is generallyused only when content is created by the DCD server or content providerand delivered from the DCD server to the DCD client.

The DCD client can also deliver (submit) content to the DCD serveraccording to the prior art. However, in the prior art, when the DCDclient submits content, the DCD client delivers the content in the formof an opaque content package that the DCD system cannot interpret,without delivering the content metadata. Thus, the DCD server can notcomprehend the content information, making it inefficient to post orshare the content, and error is apt to occur.

SUMMARY OF THE INVENTION

The present invention is designed to address at least theabove-mentioned problems and/or disadvantages and to provide at leastthe advantages described below. Accordingly, an aspect of the presentinvention provides an apparatus and method for submitting user-createdcontent to share with other users.

Another aspect of the present invention provides a method and system inwhich a user creates content according to a predetermined rule andsubmits the content with information such as a submit address, a data ormedia type, a label (or tag), etc., of the content, so that a DCDservice provider can easily handle the content after receiving it.

According to one aspect of the present invention, there is provided amethod for submitting user content in a mobile terminal. The methodincludes composing, by a user content enabled client application,content and submit-metadata representing handling information for thecontent according to a user input, generating a submit-package with thecontent and the submit-metadata, and delivering the submit-package to auser content client; submitting, by the user content client, thesubmit-package, including the content and submit-metadata, to a usercontent server; and receiving, by the user content client, a resultobtained by handling the content according to the handling informationincluded in the submit-metadata, from the user content server.

According to another aspect of the present invention, there is providedan apparatus for submitting user content in a mobile terminal. Theapparatus includes a user content enabled client application forcomposing content and submit-metadata representing handling informationfor the content according to a user input, generating a submit-packagewith the content and the submit-metadata, and delivering thesubmit-package to a user content client; and the user content client forsubmitting the submit-package including the content and submit-metadatato a user content server, and receiving a result obtained by handlingthe content according to the handling information included in thesubmit-metadata, from the user content server.

According to another aspect of the present invention, there is provideda method for submitting user content in a user content server. Themethod includes receiving a submit-package that is composed according toa user input from a mobile terminal and includes content andsubmit-metadata representing handling information for the content;submitting the content and the submit-metadata to a content provideraccording to the submit-metadata, and receiving a result obtained byhandling the content according to the handling information included inthe submit-metadata, from the content provider; and delivering thehandling result to the mobile terminal.

According to another aspect of the present invention, there is providedan apparatus for submitting user content in a user content server. Theapparatus includes a transceiver; and a processor for receiving throughthe transceiver a submit-package that is composed according to a userinput from a mobile terminal and includes content and submit-metadatarepresenting handling information for the content, submitting thecontent and the submit-metadata to a content provider through thetransceiver according to the submit-metadata, receiving a resultobtained by handling the content according to the handling informationincluded in the submit-metadata, from the content provider through thetransceiver, and delivering the handling result to the mobile terminalthrough the transceiver.

According to another aspect of the present invention, there is provideda system for submitting user content. The system includes a user contentclient for submitting to a user content server a submit-package that iscomposed according to a user input and includes content andsubmit-metadata representing handling information for the content, andreceiving a result obtained by handling the content according to thehandling information included in the submit-metadata, from the usercontent server; and the user content server for submitting to a contentprovider the content and the submit-metadata according to thesubmit-metadata included in the submit-package from the user contentclient, receiving a result obtained by handling the content according tothe handling information included in the submit-metadata, from thecontent provider, and delivering the handling result to the user contentclient through a transceiver.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features and advantages of certainexemplary embodiments of the present invention will be more apparentfrom the following description taken in conjunction with theaccompanying drawings, in which:

FIG. 1 illustrates architecture and interface configuration of a DCDservice system to which the present invention is applicable;

FIG. 2 illustrates a process in which a user submits DCD content to aDCD server and receives DCD content associated with the submitted DCDcontent according to an embodiment of the present invention; and

FIG. 3 illustrates a process in which a user submits DCD content to aDCD server according to an embodiment of the present invention.

Throughout the drawings, the same drawing reference numerals will beunderstood to refer to the same elements, features and structures.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The matters defined in the description such as a detailed constructionand elements are provided to assist in a comprehensive understanding ofembodiments of the invention. Accordingly, those of ordinary skill inthe art will recognize that various changes and modifications of theembodiments described herein can be made without departing from thescope and spirit of the invention. Also, descriptions of well-knownfunctions and constructions are omitted for clarity and conciseness.

Various embodiments of the present invention will be described below.Although the names of entities defined in the 3^(rd) GenerationPartnership Project (3GPP), which is the asynchronous mobilecommunication standard, or in the DCD of the Open Mobile Alliance (OMA),which is a standard organization for applications of mobile terminals,will be used for a description of the present invention for conveniencepurposes only, it is not intended to limit the scope of the invention,and the present invention can be applied to any similar systems.

The content submission according to the present invention can also beused for various other purposes in addition to its main purpose ofdirectly submitting certain content created by a user to share it withother users. For example, according to the content submission, the usermay submit content for submitting a keyword and/or a format needed tosearch for specific content, and may also submit content with a userpreference to receive personalized services. Besides, the user maysubmit content for his subscription to a DCD content provider server.The user may also submit the content provided from an arbitrary serviceprovider, e.g., newspaper articles.

The purposes of the content submission by the user can be divided into apurpose of submitting content to receive other content associated withthe submitted content, and other purposes, for example, for simplysubmitting content to a specific site or channel.

An example of the former case where the user submits content to receivespecific content will be described with reference to FIG. 2, while anexample of the latter case where the user simply submits content will bedescribed with reference to FIG. 3.

In an embodiment of the present invention, a DCD Enabled ClientApplication 20 and a DCD client 120 are included in a mobile terminal. ADCD server 110 includes a transceiver (not shown) for performingcommunication by exchanging messages with the DCD client 120, a contentprovider (or DCD content provider server) 10, and a personalizationsource (or personalization information provider) 30, and a processor(not shown) for controlling the message exchange and handling theexchanged messages. In the following description, the processor performsoperations associated with various message handling processes of the DCDserver 110. The DCD Enabled Client Application 20, the DCD client 120,the DCD server 110, the content provider 10, and the personalizationsource 30 perform not only the conventional functions and operations,but also the functions and operations of the invention described below.

Referring to FIG. 2, a user creates content to be submitted, using theDCD Enabled Client Application 20, and then requests content submissionby sending in step 201 a ContentSubmit Request message to the DCD client120. The user can compose the content to be submitted, according to apredetermined format. In step 203, the DCD client 120 properly adjustsinformation elements in the ContentSubmit Request message and sends instep 203 the resulting message to the DCD server 110.

The information elements included in the ContentSubmit Request messagesent in step 201 are as shown in Table 3 below, and the informationelements additionally included in the ContentSubmit Request message sentin step 203 are as shown in Table 4 below.

TABLE 3 Information Element Req Type Description Application-IDMandatory String Application identifier of the DCD-Enabled ClientApplication to which this message is related. Channel-ID MandatoryString ID of channel related to the submitted content. Submit- MandatoryStructure DCD Submit Metadata as Metadata provided by the DCD enabler.Submit-Content Mandatory Opaque Data Content to be submitted.

TABLE 4 Information Element Req Type Description Session-ID MandatoryString Session identifier. The Session-ID is unique within the serviceprovider domain. If there is an established Session, a Session-ID SHALLbe present. Message-ID Mandatory String Identifies this message. TheMessage-ID is unique within a current session. Message identifierconsists of the transaction identifier suffixed by two numericcharacters for message index within the transaction. Transactionidentifier offset is unique within the current session and identical forall messages within the transaction. Channel-ID Mandatory String ID ofchannel related to the submitted content. Submit- Mandatory list of dataOne or more submit packages. The submit package consists Packagestructures of content payload and submit metadata. If Channel-ID elementis present in the message all items in Submit- Package element belong tothe same channel (identified by Channel-ID element).

In accordance with the present invention, the user's DCD Enabled ClientApplication 20 and DCD client 120 include Submit-Metadata,Submit-Content, Submit-Package, etc. in the ContentSubmit Requestmessage for content submission in order to include therein informationrelated to the content to be submitted.

As is defined in Table 4, the Submit-Package includes Submit-Metadataand Submit-Content, and the Submit-Metadata may include the informationgiven in Table 5 below according to the present invention.

TABLE 5 Provided Data Used Originated to Name Type CardinalityDescription Type by from DECA content- E 1 Contains the followingStructure DS, CP YES metadata attributes: DC content-updated content-idchannel-id mime-type content-length content-types content-namereplaces-content-id content-price content-delivery- notificationdelivery-priority content-encoding content-addresscontent-storage-location content-block-id parental-rating deliver-todeliver-at content-expiration delivery-spread deliver-when-roamingnetwork-selection aux-content-link Contains the following sub-elementsdeliver-per-location deliver-per-presence deliver-per-xdms submit- A 0 .. . 1 An address (URI or URL) String DC, DECA YES address to which theDCD enabler DS should deliver the submit request. submit- A 0 . . . 1Identifier set by the String DC, DECA YES content-id DECA, and uniquewithin DS the DCD Service Provider's domain. display- A 0 . . . 1 Theposition where the List of DC, DECA YES position content to be displayedif Strings DS there is an agreed layout between DECA and CP. format A 0. . . 1 The format of submitted List of DC, DECA YES content (e.g. jpg,git txt, Strings DS etc.) scrap A 1 Indicates whether the String DC,DECA YES submitted content is DS allowed to scrap or not. private A 1Indicates whether the String DC, DECA YES submitted content is DSprivate or open to public. bookmark A 0 . . . 1 A point which has lastlyString DC, DECA YES submitted content. DS media- A 0 . . . 1 Media typeof the List of DC, DECA YES type submitted content (e.g. Strings DSaudio, video, image, text, etc.)

As illustrated in Table 5, the Submit-Metadata includes information suchas the relevant content's ‘submit-address’, ‘submit-content-id’,‘display-position’, ‘format’, ‘scrap’, ‘private’, ‘bookmark’, ‘label’(or ‘tag’), ‘media-type’, etc. In particular, the ‘display-position’,which is information indicating in which position the relevant contentshould be stored or displayed, can be designated by the user. Also, theSubmit-Metadata may indicate if the content to be submitted is to besimply stored, or requests other content associated with the content tobe submitted. Accordingly, the submitted content can be administered bythe DCD server 110, and shared even by other users. Because theSubmit-Metadata means supplementary metadata that can be used only whencontent to be submitted is added to the conventional content metadata,the Submit-Metadata may include the existing content metadata.

Referring back to FIG. 2, upon receipt of the ContentSubmit Requestmessage, the DCD server 110 sends in step 205 a ContentUpdate Requestmessage to the content provider 10 referring to Submit-Metadata includedin the ContentSubmit Request message in order to request content update.Information elements included in the ContentUpdate Request message areas shown in Table 6 below.

TABLE 6 Information Element Req Type Description Channel-ID MandatoryString Channel identifier for the channel offered by the contentprovider Subscription- Conditional String Comma separated list ofsubscription identifiers. Present, if IDs requesting user hassubscription IDs associated with this channel. Submit- Conditional listof data structures One or more submit packages. The submit packageconsists Package of content payload and submit metadata. If Channel-IDelement is present in the message all items in Submit- Package elementbelong to the same channel (identified by Channel-ID element). SHALL bepresent if the ContentUpdateRequest was initiated by a DCD-1ContentSubmitRequest.

Upon receipt of the ContentUpdate Request message, the content provider10 updates the content referring to Submit-Metadata included in theContentUpdate Request message. The updated content may be shared byother users according to the settings of the Submit-Metadata. Thecontent provider 10 determines whether other content related to thesubmitted content to the user should be provided, by analyzing theSubmit-Metadata. If there is a need to provide other content as a resultof the determination, the content provider 10 sends in step 207 aContentUpdate Response message to the DCD server 110. Informationelements given in Table 7 below are included in the ContentUpdateResponse message.

TABLE 7 Information Element Req Type Description Content- ConditionalList of Data One or more content packages. The content package PackageStructures consists of content payload and content metadata. Contentpayload could be empty if content-address parameter of the contentmetadata contains the address where the content could be retrieved (e.g.URI). This parameter is present when the DCD Content Provider hasupdated content to return to the DCD Enabler.

Upon receipt of the ContentUpdate Response message, the content provider10 sends in step 209 a Personalization Info Acquisition message to apersonalization source 30 to acquire personalization information, andperforms content adaptation in step 211. Through steps 207, 209 and 211,the DCD server 110 searches for or composes new content associated withthe content submitted by the user. In step 213, the DCD server 110 sendsa ContentUpdate Response message to the DCD client 120 in order toinform the user of the content updated state and provide the contentrequested by the user. The user requested content may be either specificcontent or report information indicating the execution result of thecontent submitted by the user. The ContentUpdate Response messageincludes information elements given in Table 8 below.

TABLE 8 Information Element Req Type Description Session-ID MandatoryString Session identifier. The Session-ID is unique within the serviceprovider domain. If there is an established Session, a Session-ID SHALLbe present. Message-ID Mandatory String Identifies this message. TheMessage-ID is unique within a current session. Message identifierconsists of the transaction identifier suffixed by two numericcharacters for message index within the transaction. Transactionidentifier offset is unique within the current session and identical forall messages within the transaction. Channel-ID Optional String ID ofthe channel related to the content package. If absent, the contentmetadata in the Content-Package element SHALL contain Channel-IDattribute. Content- Mandatory List of Data Structures One or morecontent packages. The content package Package consists of contentpayload and content metadata. Content payload could be empty ifcontent-address parameter of the content metadata contains the addresswhere the content could be retrieved (e.g. URI). If Channel-ID elementis present in the message all items in Content- Package element belongto the same channel (identified by Channel-ID element).

Upon receipt of the ContentUpdate Response message, the DCD client 120detects content included in the received ContentUpdate Response message,and sends in step 215 a Content message including the detected contentto the DCD Enabled Client Application 20. Information elements includedin the Content message are as shown in Table 9.

TABLE 9 Information Element Req Type Description Content- MandatoryStructure DCD Content Metadata (see Metadata Table 2) as provided by theDCD enabler. Content Optional Opaque Opaque DCD Content for the DataDCD-Enabled Client Application.

In step 217, the DCD client 120 sends a ContentDelivery Confirmationmessage for content reception confirmation to the DCD server 110.

Next, with reference to FIG. 3, a description will be made of the casewhere the user only aims to submit content.

Steps 221 to 225 in FIG. 3 are identical to steps 201 to 205 in FIG. 2,and the messages, which are sent in the corresponding steps, are alsoidentical.

However, because the embodiment shown in FIG. 3 is aimed at contentsubmission only, the content provider 10, which received theContentUpdate Request message, stores the received content and thensends in step 227 a ContentUpdate Confirmation message to the DCD server110 as a message for informing the completion of the user's contentsubmission. Upon receipt of the ContentUpdate Confirmation message, theDCD server 110 sends in step 229 a ContentSubmit Confirmation message tothe DCD client 120. Information elements included in the ContentUpdateConfirmation message are as shown in Table 10 below.

TABLE 10 Information Element Req Type Description Session-ID MandatoryString Session identifier. The Session-ID is unique within the serviceprovider domain. If there is an established Session, a Session-ID SHALLbe present. Message-ID Mandatory String Identifies this message. TheMessage-ID is unique within a current session. Message identifierconsists of the transaction identifier suffixed by two numericcharacters for message index within the transaction. Transactionidentifier offset is unique within the current session and identical forall messages within the transaction.

Upon receipt of the ContentSubmit Confirmation message, the DCD client120 forwards in step 231 the received message to the DCD Enabled ClientApplication 20. The ContentSubmit Confirmation message serves as anotification message that indicates the completion of content submissionas an internal operation of the terminal.

As is apparent from the foregoing description, embodiments of thepresent invention submit, to a DCD content provider server, content thata user created according to a predetermined rule or format and thatincludes additional information related to the content, so that the DCDcontent provider server can store or classify the DCD content and easilycontrol the DCD content when sharing it with other users.

The embodiments of the present invention can also be embodied ascomputer-readable codes on a computer-readable recording medium. Thecomputer-readable recording medium is any data storage device that canstore data which can thereafter be read by a computer system. Examplesof the computer-readable recording medium include, but are not limitedto, Read-Only Memory (ROM), Random-Access Memory (RAM), CD-ROMs,magnetic tapes, floppy disks, optical data storage devices, and carrierwaves (such as data transmission through the Internet via wired orwireless transmission paths). The computer-readable recording medium canalso be distributed over network-coupled computer systems so that thecomputer-readable code is stored and executed in a distributed fashion.Also, function programs, codes, and code segments for accomplishing thepresent invention can be easily construed as within the scope of theinvention by programmers skilled in the art to which the presentinvention pertains.

While the present invention has been shown and described with referenceto certain embodiments thereof, it will be understood by those skilledin the art that various changes in form and details may be made thereinwithout departing from the spirit and scope of the invention as definedby the appended claims and their equivalents. For example, the DCDsystem is an example of a user content system, which delivers usercontent, and the DCD client and the DCD server are also examples of auser content client and a user content server in the user contentsystem. Further, the DCD Enabled Client Application is also an exampleof user content Enabled Client Application.

1. A method for submitting user content in a mobile terminal,comprising: composing, by a user content enabled client application,content and submit-metadata representing handling information for thecontent according to a user input; generating, by the user contentenabled client application, a submit-package with the content and thesubmit-metadata; delivering, by the user content enabled clientapplication the submit-package to a user content client; submitting, bythe user content client, the submit-package including the content andsubmit-metadata to a user content server; and receiving, by the usercontent client from the user content server, a result obtained byhandling the content according to the handling information included inthe submit-metadata.
 2. The method of claim 1, wherein thesubmit-metadata includes ‘display-position’ field indicating a positionwhere the content is to be displayed.
 3. The method of claim 1, whereinthe handling result includes other content related to the content. 4.The method of claim 1, wherein the content is delivered by the usercontent server to a content provider, and stored and shared by anotheruser according to the handling information included in thesubmit-metadata.
 5. The method of claim 2, wherein the content iscomposed according to a predetermined format, and the submit-metadatafurther includes at least one of ‘submit-content-id’, ‘format’, ‘scrap’,‘private’, ‘bookmark’, ‘tag’, and ‘media-type’, each related to thecontent.
 6. An apparatus for submitting user content in a mobileterminal, comprising: a user content enabled client application forcomposing content and submit-metadata representing handling informationfor the content according to a user input, generating a submit-packagewith the content and the submit-metadata, and delivering thesubmit-package to a user content client; and the user content client forsubmitting the submit-package including the content and submit-metadatato a user content server from the user content server, and receiving aresult obtained by handling the content according to the handlinginformation included in the submit-metadata.
 7. The apparatus of claim6, wherein the submit-metadata comprises ‘display-position’ fieldindicating a position where the content is to be displayed.
 8. Theapparatus of claim 6, wherein the handling result comprises othercontent related to the content.
 9. The apparatus of claim 6, wherein thecontent is delivered by the user content server to a content provider,and stored and shared by another user according to the handlinginformation included in the submit-metadata.
 10. The apparatus of claim7, wherein the content is composed according to a predetermined format,and the submit-metadata further comprises at least one of‘submit-content-id’, ‘format’, ‘scrap’, ‘private’, ‘bookmark’, ‘tag’,and ‘media-type’, each related to the content.
 11. A method forsubmitting user content in a user content server, comprising: receivinga submit-package that is composed according to a user input from amobile terminal and includes content and submit-metadata representinghandling information for the content; submitting the content and thesubmit-metadata to a content provider according to the submit-metadata;receiving from the content provider a result obtained by handling thecontent according to the handling information included in thesubmit-metadata; and delivering the handling result to the mobileterminal.
 12. The method of claim 11, wherein the submit-metadataincludes a ‘display-position’ field indicating a position where thecontent is to be displayed.
 13. The method of claim 11, wherein thecontent provider composes other content related to the content accordingto the handling information included in the submit-metadata, andincludes the other content in the handling result.
 14. The method ofclaim 11, wherein the content provider stores and provides the contentto another user according to the handling information included in thesubmit-metadata.
 15. The method of claim 12, wherein the content iscomposed according to a predetermined format, and the submit-metadatafurther includes at least one of ‘submit-content-id’, ‘format’, ‘scrap’,‘private’, ‘bookmark’, ‘tag’, and ‘media-type’, each related to thecontent.
 16. An apparatus for submitting user content in a user contentserver, comprising: a transceiver; and a processor for receiving throughthe transceiver a submit-package that is composed according to a userinput from a mobile terminal and includes content and submit-metadatarepresenting handling information for the content, submitting thecontent and the submit-metadata to a content provider through thetransceiver according to the submit-metadata, receiving, from thecontent provider through the transceiver, a result obtained by handlingthe content according to the handling information included in thesubmit-metadata,and delivering the handling result to the mobileterminal through the transceiver.
 17. The apparatus of claim 16, whereinthe submit-metadata comprises a ‘display-position’ field indicating aposition where the content is to be displayed.
 18. The apparatus ofclaim 16, wherein the content provider composes other content related tothe content according to the handling information included in thesubmit-metadata, and includes the other content in the handling result.19. The apparatus of claim 16, wherein the content provider stores andprovides the content to another user according to the handlinginformation included in the submit-metadata.
 20. The apparatus of claim17, wherein the content is composed according to a predetermined format,and the submit-metadata further comprises at least one of‘submit-content-id’, ‘format’, ‘scrap’, ‘private’, ‘bookmark’, ‘tag’,and ‘media-type’, each related to the content.
 21. A system forsubmitting user content, comprising: a user content client forsubmitting to a user content server a submit-package that is composedaccording to a user input and includes content and submit-metadatarepresenting handling information for the content, and receiving fromthe user content server a result obtained by handling the contentaccording to the handling information included in the submit-metadata;and the user content server for submitting to a content provider thecontent and the submit-metadata according to the submit-metadataincluded in the submit-package from the user content client, receivingfrom the content provider a result obtained by handling the contentaccording to the handling information included in the submit-metadata,and delivering the handling result to the user content client through atransceiver.
 22. The system of claim 21, wherein the submit-metadatacomprises a ‘display-position’ field indicating a position where thecontent is to be displayed.
 23. The system of claim 21, wherein thecontent provider composes other content related to the content accordingto the handling information included in the submit-metadata, andincludes the other content in the handling result.
 24. The system ofclaim 21, wherein the content provider stores and provides the contentto another user according to the handling information included in thesubmit-metadata.
 25. The system of claim 22, wherein the content iscomposed according to a predetermined format, and the submit-metadatafurther comprises at least one of ‘submit-content-id’, ‘format’,‘scrap’, ‘private’, ‘bookmark’, ‘tag’, and ‘media-type’, each related tothe content.